1. Field of the Invention
The present invention relates broadly to multipoint multimedia telecommunications systems. More particularly, the present invention relates to reservation systems for the use of multimedia multipoint servers which are used in the establishment and conduct of multipoint multimedia conferences. Most particularly, the invention relates to an acceptance system which manages the allocation of Multipoint Multimedia Server (MMS) resources to specific conferences.
2. State of the Art
With the increase of throughput (data rate) available in the telecommunications industry, and in association with the improvement of compression and decompression algorithms, the number of telecommunication applications available to individuals and businesses has increased dramatically. One of these applications is called "multimedia communications" which permits video, audio, and in some cases other data to be transported from one party to another or others. Multimedia communications can be utilized for a number of applications, and in different configurations. One configuration of recent interest has been multimedia conferencing, where several parties can communicate in a conference style.
In multimedia conferencing, the audio and video data is handled such that each party can see and hear one, several, or all of the other parties. In fact, various telecommunications recommendations and standards are presently being adopted by the ITU-T, ISO, and Bellcore which govern the protocols of multimedia conferencing (see, e.g., ITU-T T.120, H.323, H.320, etc.). In the multimedia conferencing systems of the art (as represented by prior art FIG. 1), the audio, video, and other data streams generated by a user's system 12a are multiplexed together directly in the encoder section of a multimedia encoder/decoder (codec) 14 located at the source/terminal 16, and transported together through the transport network 20 (now proposed in ATM format) to a similar "peer" codec at a remote location. The peer codec is either another codec 14 at the remote user site for a point-to-point conference, and/or a codec/switch 24 at a multimedia bridge 26 (also called a Multipoint Multimedia Server or MMS) for a multipoint conference. The MMS 26, which typically includes a codec/switch 24 and a controller 28, provides conference control (e.g., it determines the signal to be sent to each participant), audio mixing (bridging) and multicasting, audio level detection for conference control, video switching (e.g., voice activated video switching), video mixing or mosaic (e.g., a quad split, or "continuous presence device" which combines multiple images for display together) when available and/or desirable, and video multicasting. The audio and video data exiting the MMS is multiplexed, and continues through the transport network 20 to the desired multimedia source terminals 12b, 12c.
It will be appreciated by those skilled in the art that the MMS is technically complex and expensive, and that use of the MMS is carefully controlled and billed to the user. In addition, it will be appreciated that because of its expense and limited availability, MMS ports are treated as rare resources. Thus, in order to guarantee to a given user the necessary resources for a desired conference at a given time, the user must reserve access to the MMS in advance of use. Reservations are made by a "reservation request" which may involve a telephone call to an operator at the company controlling the MMS or a TCP/IP connection from a client's PC to a server. In response to a reservation request, which will often include parameters such as a starting time, a duration, and resources necessary (e.g., bandwidth, mixing and switching, etc.), the operator (or PC user client) will typically access a "reservation controller", which is typically a programmed computer (specialized server), in order to determine whether the required resources of the MMS will be available at the desired time. The operator (or client) will enter information related to the desired connections and services for the given time. The reservation will be accepted only if all of the requested resources are available. Upon acceptance of the reservation, the client will be informed of codes (e.g., a reservation number, access password, etc.) required for the conference. When the time is reached for the conference, the reservation controller will inform the MMS of the beginning of a new conference and the precise resources reserved for that conference. When the users wish to join the conference and access the MMS, the users connect to the MMS, provide the reservation number (or access password), and are added to the conference, with the necessary resources having been already reserved and available.
3. Co-owned Technology
Turning to FIG. 2, a hypothetical telecommunications system is shown and includes a plurality of users 112a-112l (typically coupled to the network 20--see FIG. 1), a plurality of MMS units 126a-126d (typically located in the network), and a plurality of reservation controllers 130a, 130b (typically coupled to and/or located at the MMS units). Each reservation controller 130a, 130b, is shown coupled to two MMS units, while each MMS is shown servicing three users. It will be appreciated by those skilled in the art that depending upon its configuration and the needs of the users, each MMS can service many more than three users; and depending upon similar parameters, each reservation controller can service more than two MMS units. However, for purposes of simplicity of understanding, two reservation controllers, four MMS units, and twelve users are shown. With the provided arrangement, it will be appreciated that if users 112c, 112e, 112f, 112g, 112h, and 112j should wish to participate in a multimedia conference, the services of the four different MMS units 126a-126d will be required. Thus, the two reservation controllers 130a, 130b must be contacted to reserve appropriate access and processing of the MMS units. However, with the systems that presently exist in the art, if the MMS units and reservation controllers are owned and operated by different companies, it may be impossible to arrange such a multimedia conference. In addition, with the provided arrangement it is not evident to which reservation controller the user should forward a reservation request, and how the reservation controllers will share the information contained in the request among themselves.
As seen in FIG. 2a, and in accord with the invention disclosed in previously incorporated co-owned, allowed application Ser. No. 08/586,259, one of the reservation controllers 130a, 130b of the hypothetical telecommunications system of FIG. 2 initiates and establishes a "reservation domain" which is provided with (typically upon request) a "reservation request channeled" 135; and the other of reservation controllers attaches itself to the established reservation domain and joins the reservation request channel 135. The reservation domain is associated with a "reservation conference" (which if desired, may be pursuant to ITU-T T.124) and attachment to the reservation domain is accomplished by joining the conference. As is defined by ITU-T T.122 (MCS), any node (users, reservation controllers, MMS units, etc.) which attaches itself to a domain will be assigned a private channel (also called a "single member channel"). The private channel is normally used as a user identifier which provides a user identification and serves as an address for point-to-point communication within the multipoint domain. However, within T.122, another type of channel called a multicast channel can be defined to which any number of nodes can be joined. The reservation channel 135 is such a multicast channel.
It should be appreciated by those skilled in the art that any node which is attached to the domain can send data on any channel in the domain (the ability to send data being shown by dotted lines in FIG. 2a). However, only nodes which have joined a particular channel will receive the data sent on that particular channel (the ability to receive data being shown by solid lines in FIG. 2a). Thus, any node wishing to send private data to any other node will do so by sending this data on the private channel of the destination node, with representative private channels 147c and 147i being shown in FIG. 2a for users 112c and 112i.
A user who wishes to make a reservation will join the reservation conference and must attach himself to the reservation domain, but will not join the reservation request channel. Once attached to the reservation domain, the user can attempt to place a reservation by sending a reservation request onto the reservation request channel 135. The reservation request will typically include a plurality of multimedia conference parameters such as the starting time, the duration, the addresses of the users involved, and the resources necessary for the conference. In addition, the user will specify his own private channel address for reservation confirmation. Since the reservation controllers 130a, 130b are party to the reservation domain and have joined the reservation request channel, the parameters placed on the reservation request channel 135 are available to (i.e., are received by) the reservation controllers 130a and 130b.
Where the set of users who will be party to the multimedia conference all are serviceable by a single MMS (such as users 112d, 112e, and 112f), then the reservation controller (e.g., 130b) for that single MMS (e.g., MMS 126b) will make a determination as to whether the necessary MMS 126b resources will be available for the requested conference for the time requested. If so, the reservation controller 130b will confirm the reservation with the conference-initiating user via the private channel of the user. Where the set of users who will be party to the multimedia conference are not all serviceable by a single MMS (such as users 112a, 112b, and 112g), but a single reservation controller (e.g., controller 130a) is involved, again, the reservation controller can determine whether resources are available and can confirm the reservation with the conference-initiating user via the private channel of the user. However, where the set of users who will be party to the multimedia conference are serviced by multiple MMS units which are serviced by multiple reservation controllers, (such as users 112c, 112e, and 112f), then the reservation controller(s) (e.g., 130a, 130b) for the MMS units involved (e.g., MMS units 126a, 126b) will make determinations as to whether the necessary resources of the MMS units 126a, 126b under their control will be available for the requested conference for the time requested.
Determination as to the availability of MMS resources which are governed by multiple reservation controllers can be accomplished in several ways as disclosed in the previously incorporated co-owned, allowed application Ser. No. 08/586,259.
According to the state of the art and the co-owned technology, resources are managed and allocated, and reservations are accepted or denied on the basis of a group of requested resources. Thus, if any one of the requested resources is unavailable, the reservation will not be accepted. In other words, all of the requested resources must be available at the same starting time and for the same duration. This type of reservation acceptance system may be considered unduly restrictive since some of the resources requested for a conference may not be needed for the full duration of the conference. For example, if a conference requires an audio link and a video link for four hours and a VCR resource for one of the four hours, the VCR must still be reserved for the full four hours. Therefore, if a VCR resource is not available for the full duration of the conference, the reservation will not be accepted. On the other hand, if a VCR is available for the full duration of the conference, the VCR resource will be unavailable to others for three hours during which it is not really being used.
The state of the art reservation acceptance systems also often fail to provide a reservation requestor with much useful information other than whether a reservation has been accepted or not. Therefore, in the case of an unaccepted reservation, the requester may be left guessing as to which resource(s) were unavailable to fulfill the reservation. Moreover, the state of the art request query usually involves specifying a starting time, a duration, and a set of resources needed to conduct a conference for the duration starting at the starting time. In the case of a unaccepted reservation, the requester may need to submit multiple queries before a conference can be reserved.